1. Technical Field
The present invention relates to processing of schema changes within database management systems.
2. Discussion of the Related Art
Database management systems typically include information stored in some ordered configuration in one or more databases. For example, relational database management systems include data stored in tables, where database records are ordered in rows of the tables. Other types of database management systems include, without limitation, hierarchical based systems, such as an information management system (IMS) designed by IBM Corporation. Database schemas are provided by the database management systems to describe the organization of data and information within the databases. For example, in relational database management systems, database schemas are provided to describe the organization of data and information in tables, columns and fields within tables, indexes for the tables as well as relationships between the tables, columns and indexes. Database schemas are also provided for hierarchical based systems. A schema for a database management system in essence provides a blueprint or mapping of how the one or more databases are organized into various database organizational structures. The schema of a database management system can undergo changes for a number of different situations. For example, schema changes such as the addition or deletion of a column to a database table of a relational database management system may be necessary at times, depending upon changes in requirements to the types of data to be stored by the database management system.
Many schema changes to objects within database management systems are destructive and final. An example of a destructive schema change for a relational database management system is the dropping of a column from a database table. Such changes have a potential risk associated with them because applications which access the database management systems may still have an unknown dependency on the object that has been affected by the schema change. In addition, this dependency often remains unknown until the object affected by the schema change has been removed and errors are raised by the dependant application, which can result in costly downtime for the application.
An example approach to alleviating potential adverse affects of database schema changes would be to itemize every statement issued from every application that uses the database system. When a destructive schema change is necessary, the itemized statements can be analyzed and the impact the change will have on applications can be assessed before the change takes place. However, this approach becomes difficult due to the significantly large number of statements that would need to be itemized and kept up to date. This approach would further require some form of monitoring capability to record each and every statement, attempt to match each statement against already itemized statements, and to record the statement if it wasn't already itemized. In addition, such monitoring would need to be done for each and every application. The resulting performance overhead on applications for implementing this approach of gathering this data, and the administrative overhead of maintaining the data, renders this approach cost prohibitive.
A further drawback of to this approach is that it is only capable of detecting statements that directly reference an object to be removed. For example, this technique cannot easily detect dependencies on objects such as indexes, referential constraints, automatic summary tables, etc.
Consequently, destructive schema changes to a database are typically deferred by database administrators until there is a major re-design of an application. The undesirable result is that many redundant objects are maintained by the database management system, which in turn increases the total cost of ownership.